Now that we have covered organizing Visual Studio
solutions, it is important to make sure that we look at how we integrate
into the larger picture. That picture being the larger lifecycle of the
application we are about to create. This application may have started
before you began your efforts on the project. It will typically continue
after you have moved on to your next project. As developers we need to
make sure that we are building applications that will be able to serve
their purpose long after we are done working on them. In order to do
that we need to ensure a sound foundation and architecture, as well as
account for governance, manageability, and monitoring. Essentially, we
need to plan for the lifecycle of the application as a whole.
This brings us to
Application Lifecycle Management (ALM). ALM is broadly defined as the
application lifecycle management functions that represent a typical
software lifecycle. These functions include requirements, analysis,
development, testing, deployment, and operations, and they are
categorized into three phases.
We label the three phases
of the ALM as follows: Plan, Develop, and Operate/Monitor. Included in
the Plan phase are typically the requirements management, analysis, and
project management activities, as well as the business vision. In the
Develop phase is coding, testing, test case management, build, and
deploy. In the Operate/Monitor phase are automated monitoring and
alerting functions as well as threshold monitoring and operations
improvements. This is not an exhaustive list, but rather just an
overview of the types of activities that are found in each phase.
Visual Studio Team System
along with Team Foundation Server provides the framework required to
deliver what is needed to manage the ALM process including the Microsoft
Solutions Framework (MSF) for Agile development and MSF for CMMI
process improvement templates to quickly implement software development
practices to cover each of the three phases.
We will look at how BizTalk Server 2009
has introduced new functionality which enhances its fit into this phase
through enhancements in the Visual Studio environment, improvements to
the BizTalk project system, TFS integration, Team Test functionality,
enhanced debugging support and the inclusion of MSBuild.
1. Enhancements in the Visual Studio Environment
The enhancements that
were introduced in BizTalk Server 2009 included compiler changes,
designer changes, MSBuild support and a new project system. The compiler
changes affect all of the artifacts. In previous versions, the compiler
would take an artifact and compile it directly to an assembly. There
was no consistent way to see the code that was generated from the
designers.
In previous versions of
BizTalk you could modify the GenerateCSFiles registry key to see the
intermediate source code but that method is now obsolete. In the current
version the compiler works by doing two passes. The first creates a C#
file for every artifact and the second pass takes that C# code and
creates an assembly. Once you do a build on your project you will see
the C# files in your directory. You can also see them in your solution
by clicking on the Show All Files toolbar item.
The designer changes are
somewhat limited but bring the BizTalk development environment in line
with the .NET development environment. What that means is that you have
consistency in things like:
Property Dialog Boxes.
In previous versions
of BizTalk when you would click on the Map or Schema and select
Properties from the drop down menu you would be presented with a popup
properties dialog box that was different from the regular properties
dialog box you get when you hit F4, and that is located in the
bottom-right corner of Visual Studio. For developers who were new to
BizTalk, this was quite confusing and didn't make sense why this was
separated from the rest of the properties. In BizTalk 2009 the data that
was contained on this popup properties dialog box has now been
integrated with the standard Visual Studio properties dialog box.
Build Types.
Build types are consistent
with .NET project types and now use the Release and Debug key words
instead of the Development and Deployment key words. However, you will
continue to see the Development and Deployment configurations for the
projects that are migrated from BizTalk Server 2006 R2.
Lastly, it is hard to talk about
enhancements without mentioning that BizTalk now takes advantage of the
latest versions with support for Visual Studio 2008, the .NET framework
3.5, SQL Server 2008 and Windows Server 2008.
2. Improvements in the BizTalk Project System
The project system is where
some of the largest changes in BizTalk 2009 were introduced. The
improvements in the BizTalk project system included the complete
overhaul of the .btproj project file. The project file is now a
"flavored" version of the baseline C# project file. What this means is
that the features found in C# project types will now be available in the
BizTalk project types. Flavoring involves creating a project system on
top of an existing base project to provide customized functionality that
is not available through the base project system. By doing this,
BizTalk is able to leverage several important features such as an
integrated designer and debugging experience, build & validate error
navigation, source control and TFS integration, and exposing project
assembly properties through the AssemblyInfo.cs file. Project flavoring
provides additional customizations such as deployment, project item
properties, MSBuild support, add web reference, BizTalk build install
options and additional functionality around errors and error navigation.
In the previous section we
mentioned the combined properties dialog box. Property settings from
that dialog box are now located in the .btproj.user file. Since the
settings are stored in this file in plain text they can be manipulated
outside of Visual Studio by unit testing frameworks or continuous
integration systems.
One thing to keep in mind is
that the .btproj.user file is typically not included when checking code
into source code repositories. It will be up to your individual
preferences if you want that file checked in and available to all of the
developers on your team.
The storing of properties in the
.btproj.user file, along with the changes to the .btproj file, provides
additional options in the ALM cycle. You now can have custom test tasks
and build tasks modify the data in these files to change and automate
the way that tests run and the way that builds occur. Continuous
integration and build scripts are examples of this type of automation.
Another feature that has
changed is that the Embed Tracking Information and Generate Debugging
Information output configuration properties have been replaced by the
Define TRACE constant and Define DEBUG constant build options on the
Build tab of Project Designer. This further brings the development
experience in sync with what you get when doing standard, .NET
development.
Lastly, by using the
flavored project type and the features of MSBuild, BizTalk developers
can now build projects without Visual Studio. This means that having
your BizTalk solution files on a computer that has MSBuild, you will be
able to build BizTalk projects without having BizTalk or Visual Studio
installed. Using a build server for BizTalk is so much easier and no
longer requires anything additional to what we have always used for .NET
builds. In addition, the build process is incremental. Each BizTalk
artifact is a C# class and therefore when building a project only those
classes that have changed will be built thus shortening the time it
takes to build BizTalk projects.
3. TFS Integration
BizTalk Server 2009
provides tighter integration with TFS then any of its predecessors. This
integration includes source control, bug tracking, automated unit
tests, automated builds, and the ability to perform continuous
integration.
When looking at the build and
deploy phase of the development process, you probably want to be able to
take a BizTalk solution and check in updated files, kick off a build
(and have it complete without errors), perform unit tests, perform a
deployment, and then run a set of build verification tests (BVTs). All
of this is now possible with TFS and BizTalk.
Continuous integration refers to the practice of frequently integrating your code with the rest of the codebase that will be released.
To take advantage of
continuous integration within TFS, start by creating a new build
definition inside of Team Explorer. When the Build Definition dialog box
appears, set the Workspace setting to your source control folder, and
then click the Project File section. Click Create to make a new build
project. When the wizard appears, select your solution, and continue to
follow through the wizard pages. Next select your build type in the
Configurations section, and click Next to move to the Options page. Next
you can select the Run Tests check box and click your unit tests that
you created as part of your solution. Click Finish to save the settings
in the wizard.
At this point, you are back in
the Build Definition dialog box. Move to the Build Defaults section, and
select New to create a new build agent. Fill in the values according to
your environment, and click OK. Once back in the Build Definition
dialog box, fill in the network share location for the builds to be
copied. You are now at the last step, the Trigger section. In this
section, select the "Build each check-in (more builds)" radio button,
and click OK. You now have an automated solution to provide you with a
continuous build system.
At a high level, an
organization that is looking to take full advantage of their investment
in these technologies should look to implement a fully streamlined
process, which includes the ability to take a BizTalk solution and move
it through the build, unit test, deployment, and BVT tasks in an
automated and consistent manner.
4. Enhanced Debugging
There were a number of enhancements in the area of debugging. The one we will cover here is Map debugging.
Map debugging is now included
on the popup menu on the map file. When you select this option Visual
Studio will open a debug session with the generated XSLT. You can
provide input instance and start stepping through each line of the XSLT.
The debugger will also let you debug script code in certain instances.
As you walk through the
lines of code you can hover over variables to see their values. There
are a couple of things to keep in mind when debugging. The debugger does
not support maps with multiple input schemas nor does it support maps
that use extension objects.
Now that we have covered
the ALM experience and how the development effort fits into the larger
effort, we can talk about organizing artifacts in BizTalk.
